Solution

Exercise 1: GuessInput

View solution code on Github

You can learn more about the npm run new-component command in the “Getting Started” video.

Switching from “minLength” to “pattern” (warning)

In the video above, I mentioned that the minLength attribute sometimes seems not to work. Several other students have run into this issue. It turns out, bewildering, that the .toUpperCase() is to blame!

The reason I wasn't running into the problem in the video is because I was holding “shift” as I typed. The issue occurs when the .toUpperCase() method actually changes the characters entered.

This isn't a problem with React specifically; I was able to reproduce the same issue in vanilla JavaScript and HTML. For some reason, transforming the value on an input causes the minLength attribute to fail.

To address this issue, I've updated the solution to use the pattern validation attribute instead:

<input
  required
  minLength={5}
  maxLength={5}
  pattern="[a-zA-Z]{5}"
  title="5 letter word"
/>

The pattern attribute uses Regular Expression syntax. Specifically what we're saying here is that the acceptable characters are letters ([a-zA-Z]), and that there should be exactly 5 of them {5}.

We also add the title attribute for clarification; if the user tries to submit the form and the validation isn't met, they'll be shown a message like this:

I decided to keep minLength and maxLength even though they're being overruled by pattern; hopefully, browsers will fix this issue someday and we can remove the pattern and title.

I've also removed the conditional window.alert from the solution as well, since this validation works reliably.

Exercise 2: Keeping track of guesses

View solution code on Github

We see some modern JS tricks in this one, including spread syntax 👀, array destructuring 👀, and object destructuring 👀. Check out those respective lessons in the JavaScript Primer bonus module if you're not sure how they work!

Exercise 3: Guess slots

View solution code on Github

Exercise 4: Game logic

View solution code on Github

A different structure? (success)

Several students have taken a different approach for this one: they've evaluated the guess before adding it to the state, like this:

function Game() {
  const [guesses, setGuesses] = React.useState([]);

  function handleSubmitGuess(tentativeGuess) {
    const checkedGuess = checkGuess(tentativeGuess, answer);
    setGuesses([...guesses, checkedGuess]);
  }

  return (
    <>
      <GuessResults guesses={guesses} />
      <GuessInput handleSubmitGuess={handleSubmitGuess} />
    </>
  );
}

At this point in the course, we're still getting comfortable with the fundamentals, and either solution is 100% valid. You can absolutely solve it this way!

That said, one of my “happy practices” is to store the minimum amount of stuff in state, and to derive things whenever possible.

Later in the course, we'll revisit this exact problem, and I'll share my rationale for why I prefer to store the “raw” guesses in state. It's not something you need to worry about now though. 😄

Importing instead of passing props? (warning)

In my solution, I pass the answer prop through the application, so that our Guess component can tell whether the guess is correct or not.

Some students have instead solved this problem by exporting the correct answer and importing it in the Guess.js file, and have wondered if this is an acceptable approach.

This is totally valid. Honestly, it keeps the code a lot simpler!

So why didn't I do it this way? Well, here's the catch: it only works for immutable data. We aren't allowed to ever update or change an import.

One of the stretch goals for this project is to implement a "restart" feature, where the user can start again with a brand-new word. In that case, answer changes over time, and so we can't rely on import/export.

Similarly, in real-world projects, we're often dealing with data pulled from a database and sent over the network. In these cases, we also can't rely on import/export, because the data isn't known at first.

That said, for this exercise, either approach is acceptable. You can always refactor later if you want to give the stretch goal a shot!

Exercise 5: Winning and losing

View solution code on Github

You can view all of the final code on the “solution” branch on Github.

Stretch Goals

View solution code on Github

This solution solves the two stretch goal examples provided:

Adding a visible keyboard.
Adding a “restart” button when the game ends.